Method for matching bidirectional objects

ABSTRACT

A method for pairing a bidirectional object acting as a command receiver with a bidirectional object acting as a command transmitter, includes the stages of: (a) temporary allocation of at least one bidirectional object acting as a command receiver to a bidirectional object acting as a command transmitter; (b) selection of a bidirectional object acting as a command receiver from among the temporarily assigned objects; and (c) pairing of the selected object.

FIELD OF INVENTION

The invention relates to the field of transmitters of commands andreceivers of commands having transmit and receive capabilities; it inparticular relates to transmitters and receivers in home automationsystems.

BACKGROUND

Such home automation systems are used for motorized products orautomatic devices for closing or solar protection in the building, orfor the control of lamps or other systems. Typically, one or morecommand transmitters are provided; each device to be controlled—rollingshutter, blind, lighting unit, etc.—is associated with a commandreceiver; it is also possible for provision to be made for severaldevices to be controlled by a same command receiver. The commandtransmitters and command receivers communicate by radio and use the sametransmission frequency, or predetermined frequencies. For these devices,and in particular for motorized products or automatic devices forclosing or solar protection in buildings, logistic reasons most oftennecessitate that the pairing is not performed during manufacture, butrather on the worksite, after installation of the products. Variouspairing solutions are proposed in the state of the art.

Certain solutions relate the case where command transmitters are capableonly of transmitting and where command receivers are capable only ofreceiving. U.S. Pat. No. 4,750,118 or U.S. Pat. No. 6,049,289 areexamples of such solutions.

Other solutions use command transmitters and command emitters capable oftransmitting and receiving; U.S. Pat. No. 4,529,980, or U.S. Pat. No.5,148,159 are cited in particular.

WO-A-01 71685 discloses a universal remote controller, suited tocontrolling various units. Each unit contains a record of the variousdata necessary to allow the controller to manage it remotely, with adevice code in particular; the record is copied into the universalcontroller. This document proposes that the controller interrogates thevarious units that it controls successively.

U.S. Pat. No. 5,797,085 describes a communication system in which thedifferent objects are not paired. On the contrary, the objects areidentical from the communication point of view and do not have an uniqueaddress.

EP-A-0 651 119 describes a set of transmitters and receivers, andmentions the pairing problem. Pairing is effected by learning a code forone transmitter from another transmitter. The two transmitters areplaced side by side and the button for the channel in question ispressed on each transmitter, starting with the “teaching” transmitter.This gradual method of learning the codes is also applied to thereceiver. The document envisages inhibiting the code teaching functionon some transmitters.

U.S. Pat. No. 6,028,866 describes a communication system in which eachdevice includes a communication identification, which is allocated inthe factory or by the user. For a group constitution, a central devicesends a message inviting devices to join the group. On receipt of aninvitation message, a device responds as, appropriate with an acceptancemessage. The central device stores a list of the devices forming thegroup, i.e. the devices that have responded with an acceptance message.Said procedure for forming a group allows messages intended for thegroup to be sent.

The French patent application filed by the applicant on 13 Jul. 2001under the number 01 09369 describes a method for pairing transmitter andreceiver. This application specifies that an installer can be suppliedwith a programming console. Each of the receivers is thus also atransmitter, and the programming console is therefore not only atransmitter but also a receiver. In the pairing phase, receivers send anidentification number which is unique to each of them to the console.The software contained in the console allows the receivers that areknown to it to be classified. The installer therefore has the option tosend commands successively, each of which will be recognised only by thesingle receiver in question, and then to pair said receiver, which isthus identified physically by responding to said command, with thetransmitter intended to control it thereafter. In this solution, it isproposed that a specific console be used; this is not itself paired withthe receiver, but which is used first to identify the receiver and thento pair the latter with the transmitter.

There is therefore a requirement for a method for pairing objects whichare capable of sending as well as receiving which is both simple andreliable. Such a method must maintain its reliability even in a radioenvironment or heavily loaded network—for example in the presence ofneighbouring products which have been configured previously, orneighbouring products undergoing configuration.

SUMMARY

In one embodiment, the invention therefore proposes a method for pairinga bidirectional object acting as a command receiver with a bidirectionalobject acting as a command transmitter, comprising the following stages:

-   -   (a) temporary allocation of at least one bidirectional object        acting as a command receiver to a bidirectional object acting as        a command transmitter;    -   (b) selection of a bidirectional object acting as a command        receiver from said temporarily allocated objects; and    -   (c) pairing of the selected object.

The selection and pairing stages can be repeated. A stage releasing theobjects allocated temporarily distinct from the paired object or pairedobjects can then follow.

In one embodiment, the temporary allocation stage comprises:

-   -   (a1) in response to an initiator event, the sending of its        identifier by at least one bidirectional object acting as a        command receiver;    -   (a2) sending by a bidirectional object acting as a command        transmitter of its identifier;    -   (a3) storage by a bidirectional object acting as a command        receiver of the identifier of a bidirectional object acting as a        command transmitter and    -   (a4) storage by the bidirectional object acting as a command        transmitter of the identifier of each bidirectional object        acting as a command receiver.

In this case, the (a1) stage may include sending with the identifier atime reference dependent on the initiator event.

The (a4) stage may also include storage of the identifiers ofbidirectional objects acting as command receivers having identical orsimilar time references.

In another embodiment, the selection stage comprises:

-   -   (b1) sending a response request command from the object acting        as a command transmitter to one of the objects allocated        temporarily;    -   (b2) a response from that object allocated temporarily to which        the response request command is sent;    -   (b3) if the object that has responded is not the wanted object,        repetition of the stage of sending a response request, but to        another of the objects allocated temporarily.

The release stage may again comprise the release of objects allocatedtemporarily distinct from the paired object if a command is not receivedduring a set period. Alternatively, the release stage may comprise therelease of an object allocated temporarily on receipt of a pairingcommand directed to another object allocated temporarily or even thesending by the object acting as a command transmitter of a releasecommand.

In one embodiment, the pairing stage comprises the pairing to theselected object of the bidirectional object to which the selected objectwas allocated. A bidirectional object differing from the bidirectionalobject to which the selected object was allocated may also be paired tothe selected object.

The invention also proposes a method for operating a bidirectionalobject acting as a command receiver, comprising:

-   -   (a) a stage of temporary allocation to a bidirectional object        acting as a command transmitter; and        -   as desired, either of the two stages of    -   (b) pairing to a bidirectional object acting as a command        transmitter, or    -   (c) release, ending the temporary allocation.

In one embodiment, the temporary allocation stage comprises:

-   -   (a1) in response to an initiator event, sending an identifier;    -   (a2) reception of an identifier;    -   (a3) storage of the received identifier.

The sending stage may thus comprise the sending with the identifier of atime reference dependent on the instant of the initiator event.

Advantageously, the release stage should comprise release on receipt ofa pairing command addressed to another object. Said release stage mayalso comprise release on receipt of a release command.

In one embodiment, the pairing stage comprises pairing to saidbidirectional object acting as a command transmitter. However, pairingmay also comprise pairing to a bidirectional object other than saidbidirectional object acting as a command transmitter.

The invention also proposes a bidirectional object having:

-   -   a reception stage;    -   a transmission stage;    -   a logic unit controlling the transmission and reception stages        and implementing said method of operation.

The invention also relates to a method for operating a bidirectionalobject acting as a command transmitter, comprising the following stages:

-   -   (a) sending a temporary allocation command;    -   (b) reception and storage of the identifier of at least one        bidirectional object acting as a command receiver;    -   (c) sending a response request command to one of the objects        whose identifier has been stored;    -   (d) depending on an instruction from the user, sending (116) of        a pairing command to said object.

The stages of sending a response request and sending a pairing commandcan be repeated. After the pairing stage, a command can be sentreleasing the objects whose identifiers have been stored, as distinctfrom a paired object to which the pairing request command has been sent.

Advantageously, the reception stage should comprise a comparison of thetime references received with said identifiers and storage ofidentifiers having identical or similar time references.

Stage (c) may also comprise

-   -   (c1) sending a response request command to one of the objects        whose identifiers have been stored;    -   (c2) sending a response request command to another of the        objects whose identifiers have been stored;        and stage (d) may comprise sending a pairing command to the        object to which the previous response request command was        addressed.

It is also advantageous that stage (e) comprises the sending of arelease command. At stage (d) the pairing command can contain anotherobject's identifier.

Finally, the invention relates to a bidirectional object having:

-   -   a reception stage;    -   a transmission stage;    -   a logic unit controlling the transmission and reception stages        and implementing said method of operation.

BRIEF DESCRIPTION OF DRAWINGS

Other characteristics and advantages of the invention will becomeapparent on reading the description which follows, given by way ofexample and by referring to the drawings which show

FIG. 1, a schematic view of an installation according to the invention;

FIG. 2, a schematic view of the logic structure of a bidirectionalobject allowing implementation of the invention;

FIG. 3, a flow chart of a method of pairing according to the invention;

FIG. 4, a flow chart of a method to secure the definition of a groupamong the bidirectional objects;

FIG. 5, a flow chart of a method implemented in a command receiver; and

FIG. 6, a flow chart of a method implemented in the command transmitter.

DETAILED DESCRIPTION

In the description which follows, the invention is described in anexample of its application to the pairing of home automation systems; itis not limited to such systems; it can also be used for purposes otherthan pairing. Hereinafter, the terms “command transmitter” and “commandreceiver” are used to describe objects whose function is to transmit orreceive commands given by a user; said descriptions are notrepresentative of “transmitter” or “receiver” functionalities which,from the point of view of the signals, are capable both of sending andreceiving. The term “bidirectional object” thus could have been used,i.e. an object having both transmit and receive capabilities. Forclarity in the explanation, the terms “transmitters” and “receivers” areused—which only represent the allocation of a given bidirectional objectto a particular use.

It is also assumed in the following description that each bidirectionalobject is given an univalent identifier; this may be an identifiercorresponding to an object code set in the factory and which cannot bechanged; it may also be a number which can be changed, such as a randomnumber chosen in the object or even a number chosen usingmicro-switches. The origin of the identifier has no effect on thefunctioning of the method. It will also be noted that the identifierused hereinafter may be changed after pairing; it is simply used toidentify the object during pairing.

FIG. 1 shows a schematic view of an installation in an initial exampleof the implementation of the invention. The installation includes anoperator 2. Said operator can, for example, roll blinds up or down, openor close rolling shutters or a garage door, switch a light on or off,open a door, trigger or clear an alarm, etc. The operator is connectedto a command receiver 4, referenced in the figure by the letter “R”. Thecommand receiver has an antenna 6 which allows it to receive commandssent by radio link from a command transmitter, the command receiver 4can moreover transmit signals, for example by radio link, using the sameantenna 6. The transmission by radio of commands from a transmitter to areceiver or vice versa is known per se and is not described here in moredetail.

FIG. 1 also shows a plurality of operators 8, 12, each with theircommand receiver 10, 14. It also shows a command transmitter 16; this issuited to transmitting by radio link one or more commands addressed tothe receivers 4, 10, and 14 and has an antenna for this purpose (notshown). Typically, a command transmitter, in the case of controlling arolling shutter, can transmit commands to raise or lower the shutter, orto stop the shutter; other commands can also be given, such as placingthe shutter in pre-programmed positions, commands for programming theshutter, etc. The command transmitter thus has one or more devicesallowing the user to enter a command, in the simplest case one or morecontrol buttons. The command transmitter is also capable of receivingsignals from the command receiver(s); as with the command receiver, thesame antenna is used.

Thus, according to the command received from the user, its operatingprogram and/or signals received from the command receivers, the commandtransmitter sends signals, as explained below.

A number of transmit or receive channels can be provided for the commandtransmitter and the command receiver; in a simple configuration, radiois used, and thus the transmitter as a sender is a “transceiver”, i.e. atransmitter and a receiver.

The problem for the invention is to pair a command transmitter to acommand receiver, or in other words to ensure that commands sent by anycommand transmitter allow the operator to be switched on or off by meansof the command receiver—while commands sent by other commandtransmitters have no effect. Once such pairing is effected, there aresolutions which allow other command transmitters to be added, forexample, to create a general command, i.e. a command transmitter capableof commanding a number of command receivers.

To this end, the invention proposes that a command receiver sends itsidentifier when an initiator event is present. Subsequently, if acommand is received from a command transmitter, the command receiver isallocated temporarily to said command transmitter; in other words, itdoes not respond, or no longer responds, to commands received from othercommand transmitters; the allocation is merely temporary and thus is nota pairing.

Said “temporary allocation” is used to pair a command receiver that hasbeen subjected to an initiator event, even in a dense radio environmentin which numerous messages are sent.

In terms of states, a command receiver therefore has three distinctstates. In the first state, the receiver is not paired. In the secondstate, the command receiver is allocated temporarily to a commandtransmitter. The third state is a pairing state. The command receivermoves from the first state to the second state after the initiatorevent, when it receives a command from the command transmitter. Thecommand receiver moves from the second state to the third state when itreceives a pairing command. As shown below, once the command receiver isin the third state, it no longer responds to an initiator event.

FIG. 2 is a schematic view of the logic structure for a bidirectionalobject used as a command transmitter or as a command receiver. In theexample shown, the object is a “transceiver” and sends and receivessignals by radio link, using a single antenna. The object 20 thereforehas an antenna 22, a receive stage 24, linked to the antenna; thereceive stage receives signals picked up by the antenna 22. It also hasa transmit stage 26, it is also linked to the antenna 22, whichtransmits signals to be transmitted to the antenna. The transmit andreceive stages are controlled by a logic unit 28, such as amicroprocessor, which is capable of executing a program stored in amemory 30, typically a read-only memory. The object also has aread-write memory 32 whose content can be changed while the object isfunctioning.

According to its allocation as a command transmitter or as a commandemitter, the power source feeding the object can vary; typically acommand transmitter is a portable device, fed by a cell or battery; acommand receiver is connected to the operator and is thus fed from themains.

A command transmitter and a command emitter may also differ in theoperating program stored in the memory 30—insofar as it is advantageousto limit the size of the memory 30, to differentiate the objects byloading into memory an operating program which is designed only for thesole functionalities of a command transmitter (or command receiver).

The identifier of the object is stored in the read-only memory 30, orcan even be stored in the memory 32, if it is generated at random orotherwise.

The means which allow an object to respond to a user command are notshown; these may be buttons, contacts, switches or other, both forcommand transmitters and command receivers. It can also be envisagedthat the object is sensitive to one or more power cuts; this isparticularly advantageous for a command receiver, as shown below.

FIG. 3 is a flow chart for a method of pairing, in one embodiment of theinvention. The start point (stage 40) is assumed to be the existence ofa number of bidirectional objects intended to function as “commandreceivers” and a bidirectional object used as the command transmitter.

At stage 42, an initiator event is produced by the user; this is anexternal command—i.e. it is not sent by a command transmitter. Forexample, it may be a specific action on the command receiver powersupply, typically a double break to the mains power. This solution hasthe merit of being simple to implement, insofar as command receivers aregenerally connected to the mains, as explained earlier. It is alsoconceivable that the initiator event results in a command receiveractioning a local command, or a local change to the branch powersupplies; said solution in particular allows a command receiver to bere-paired, even if it had been paired beforehand. In every case, theinitiator event is detected by the command receivers.

Receipt of a command sent by a command transmitter could also be used asan initiator event; said solution could be used to pair a commandreceiver from among those that could receive the command in question.This solution has the drawback that command receivers cannot beselected—unless it is assumed that they are already paired to a givencommand transmitter. The combination of an external command and acommand sent by a command transmitter could also be used as theinitiator event; the external command—for example a local action on thereceiver—is used to select the command receivers that must respond; thecommand send by the command transmitter is used for synchronism, whichcan be useful, as described later.

At stage 44, in response to the initiator event, a command receiver thatmust be paired sends a signal representing its identifier and anindication which is available for pairing. As has just been mentioned,these may be command receivers which have never been paired previously;they may also be command receivers which have been paired previously andwhich need to be re-paired. The signal sent in this case is the mostsimple, formed from the identifier of the command receiver and aspecific code signaling that it is available for pairing; an alternativeis to send only the receiver identifier, in a specific format.

This transmission can be repeated at regular intervals for apredetermined period—for example 2 to 3 minutes. If a number of commandreceivers are sending—which is the most likely assumption—theconventional rules for detecting collision and repetition can be usedduring the transmission. The predetermined time is selected according tothe rules of detection, collision or repetition, and the maximumacceptable number of command receivers transmitting during this stage.

On completion of this stage, the command receiver(s) that has/havereceived the initiator event have sent their identifier(s); in this way,an “auditor” of the signals sent recognises which command receivers haveresponded to the initiator event; a command transmitter active duringstage 44 can thus build up a list of the command receivers that havetransmitted during this stage.

At stage 46, a command transmitter is switched on and sends a signalrepresentative of its identifier and a temporary allocation command. Thecomments made at stage 44 on the structure of the signal sent remainvalid, mutatis mutandis, for this signal and subsequently for the othersignals transmitted.

Stages 46 and 44 can be reversed; this ensures that the commandtransmitter is active when the command receivers send their identifiers;conversely, the command transmitter can be set up before the initiatorevent, by “telling” it by means of a local action that it must “listen”for command receivers.

At stage 48, the command receivers that have transmitted theiridentifiers at stage 44 record the identifier of the command transmitterin a memory. For a predetermined period, said command receivers willrefuse to obey any command which does not originate from this commandtransmitter. These receivers are therefore allocated temporarily to thecommand transmitter which sent the temporary allocation command at stage46. It will be noted here that the identifier transmission by thecommand receiver at stage 46 is only to facilitate the temporaryallocation of the command transmitter and the command receivers. Atemporary identifier could be used for this single temporary allocation.

The predetermined time for the temporary allocation is used for thetemporary pairing of a command transmitter and a command receiver; itcan be fixed—and, in this case, the command receivers revert to normaloperation on expiry of this period. As explained later, the temporaryallocation may only cease on transmission by the command transmitter ofa release command or of a command ending the temporary allocation.

On completion of this stage 48, the command receiver(s) that wereidentified at stage 44 and which received a temporary allocation commandat stage 46 will now only obey commands received from the commandtransmitter; the command transmitter which sent the temporary allocationcommand itself has a list of command receivers. It thus becomes possibleto proceed with the pairing, or any other manipulation involving thetransmitter and the receivers, independently of the radio environment.This temporary allocation guarantees correct identification of thebidirectional objects in question, in a dense network or radioenvironment, in which numerous messages are sent by previouslyconfigured objects—for example, neighbouring apartments—or in whichother objects in neighbouring installations can themselves be in aconfiguration phase.

The use of this temporary allocation for pairing will now be described.The pairing is based on scanning the list of command receivers built upduring the preceding stages. The use of a screen for the scanning if thecommand transmitter is a genuine programming console is conceivable but,more simply, this will be by pressing a push button if the commandtransmitter is a simple remote control.

At stage 50, the command transmitter sends a signal representative ofits identifier and a response request command addressed to a receiver inthe list—for example the first on the list. The purpose of the responserequest is to allow the user to determine visually, audibly, or by anyother method, the receiver addressed. If the command transmitter is aremote control, the Stop command can be used to send this signal.

At stage 52, on receipt of the response request command, the receiverconcerned responds with a signal. This signal may be the abbreviatedcommand from the operator controlled by the receiver concerned; such asignal allows the user to identify the receiver.

At stage 54, the user determines whether the signal sent at stage 52 hasoriginated from the desired receiver or not. If this is the case, thenext stage is 56, and if not, stage 58.

At stage 58, another receiver on the list is polled—for example, thenext receiver. This corresponds to sequential scanning of the list; thelist can also be scanned at random. The next move is to return to stage50, to issue a fresh response request addressed to this other receiver.The same command from the command transmitter is used to move to anotherreceiver.

At stage 56, the receiver to be paired has responded to the responserequest command. It is therefore possible to proceed with the actualpairing; this is done using the command transmitter allocatedtemporarily, by sending a signal representative of the transmitteridentifier and a pairing command addressed to the receiver to be paired.An identification key can be sent from the command transmitter, anotheridentifier to be used subsequently, or any other information necessaryfor the pairing. The Prog programming button on a remote control can beused.

The command transmitter is thus used as a simple programming console; inthis case, a receiver becomes receptive to a pairing command afterhaving responded to a response request command. A receiver remains inthis state for a set period, until it receives a pairing command, oruntil it receives a fresh response request command from the commandtransmitter to which it is allocated temporarily and which is addressedto another receiver. Thus, at stage 56, the command receiver which haslast responded to a response request command can be paired simply bysending a pairing command using the command transmitter to be paired;said solution has the advantage of allowing the scanning of the list tocontinue using the command transmitter used at stage 46, the commandreceiver which was the last to respond now being paired. Having beenpresent during the pairing procedure, the command transmitter used asthe programming console can exclude from the list of receivers theidentifier of the command receiver now paired. Hence the same object canbe used as a tool to nominate successively each object to be paired, butwithout being paired itself. This object can itself be very simple anddoes not have more control buttons than a traditional control point.

Regardless of the command transmitter to be paired, the command receiverstores in a memory the identifier of the command transmitter, in orderthat it can then respond to commands which it receives from it. It movesinto a paired state, in which it no longer responds to an initiatorevent such as a double power cut, but only to a particular initiatorevent—a local action or even a re-pairing command from the commandtransmitter to which it is paired.

The pairing described summarily at stage 56 can be more complex andincludes multiple exchanges between the transmitter to be paired and thereceiver; new identifiers, authentication keys, encrypted data, arotating code, or others, according to the authentication process usedhereafter can be sent.

There are potential variants to these two pairing solutions; thus, theremight be pre-pairing between the command transmitter used as theprogramming console and the command transmitter to be paired; in thiscase, for the pairing, the command transmitter used as the programmingconsole would send an identifier to the command transmitter to bepaired. This solution has the advantage of affording greater security,even if the command transmitter that has sent the temporary allocationcommand is not paired.

On completion of the pairing stage 56, a command transmitter is pairedto the command receiver which last responded to the response requestcommand. At stages 60 and 62, the other receivers allocated temporarilyare released if appropriate. As explained earlier, these stages are notessential; the receivers can be programmed such that the temporaryallocation ceases after a set period; the temporary allocation can alsobe ceased on receipt of a pairing command, even if addressed to anothercommand receiver.

However, it is advantageous to give the user the option to continuepairing receivers from the list other than the one that has just beenpaired. This avoids the requirement to re-send the initiator event topair the other receivers. At this stage 60, the user is prompted as towhether he wishes to release the other receivers. If this is the case,he moves to stage 62, where the release command is sent; if not, hereturns to stage 50, in order to send a new response request command;stages 60 and 62 can be implicit; thus, if the command transmitter isused as a programming console, the stage 62 test consists simply ofconfirming whether the user has pressed the button again to send aresponse request command—which results in a move directly to stage 50.In the absence of such a response request command, a move to stage 62would be the result, unless release was implicit on the elapsing of aset period. Conversely, it is equally conceivable that a new initiatorevent could be sent at stage 62, in the form a specific commandaddressed to receivers on the list as yet unmatched.

The method described at FIG. 3 allows certain pairing, regardless of theradio environment.

The method described can be used by referring to FIG. 4, to secure evenmore from this combination and avoid, in a complex installation, orneighbouring a complex installation, any overlapping of objects that mayhave been paired, although they do not belong to a single group. Thismethod is used to define an initiator event with more certainty, inorder thus to form a group among the bidirectional objects.

The method is based on the synchronous character of the initiator event;it proposes to use said event as a time reference; said reference allowsa command receiver that has received the initiator event to beidentified from its local time, measured against said time reference. Itis thus sufficient that a command or a response sent by a commandreceiver is accompanied by an indication of the local time, as will nowbe described.

The synchronous initiator event is produced at stage 70; as explainedearlier, this can be an external command—in the example, a given actionon the mains. It may also be a combination of an external command and acommand received from a command transmitter, as explained above.

At stage 72, each command receiver that has detected the initiator eventstarts a timer.

At stage 74, a command receiver sends a signal; this may be the signalfrom stage 44 of FIG. 3, or any other signal sent subsequently by thecommand receiver; said signal includes an indication from the timer, aswell as the identifier of the command receiver. Hence the signal sent bythe command receiver is dated with reference to the time reference thatconstitutes the initiator event.

At stage 76, the signal sent at stage 74 is received by the object towhich it is addressed—for example the command transmitter. Thereforethis also has the timer indication. At stage 78, this indication iscompared with an indication calculated locally in the commandtransmitter; this indication results from a comparison with the timeindications received from other command receivers. It may also come froma command transmitter timer—particularly if this originated theinitiator event.

If the time indication of the received signal is consistent, the nextmove is to stage 80, in which the instructions or commands sent by thecommand transmitter are processed; conversely, if the time indication isinconsistent with the indication calculated locally, the next stage is82. At stage 82, it is known that the signal sent at stage 76 isinconsistent and that the signal received at stage 76 did not come froma command receiver that had been subjected to the initiator event. Themessage or the instructions received are ignored.

The method of FIG. 4 thus allows the origin of a message to beidentified with more certainty; it is used to secure the constitution ofgroups using an initiator event.

There are possible variants of the method described in FIG. 4. Thus, ifthe command transmitter cannot itself detect the initiator event—forexample, because the command transmitter is a roving object, notconnected to the mains—it can nonetheless trigger its own timer at theinstant of its first activation. The counter settings collected in eachframe are thus decremented by the setting of the command transmittercounter before being recorded with all the command receiver identifiersduring the capture. At the end of the capture phase, these settings areall compared and these will differ to some degree from the mean settingcorresponding to the identifiers which are not included.

The way in which the time reference is coded can also be changed. Thus,if the various objects are fitted with an internal timer—for example, toallow time programming by the user—they cannot start a counter, butsimply note the date and time of the initiator event. Said date and/ortime can then be sent in a message.

The stage 78 consistency test depends on the desired accuracy andcomputer drift. For timers as currently used on rolling shutters, with adrift of some 300 ms/hour, it is considered that objects which havereceived a single initiator event must respond with a time indication ofapproximately 10 ms, for a stage 44 duration supposed to be limited totwo minutes. This allows differentiation between initiator eventsseparated by less than 100 ms, and in practice makes any confusionbetween two groups of objects extremely improbable.

In the example of FIG. 4, the insertion of a time indication intomessages sent by command receivers to a command transmitter isdescribed. The method of FIG. 4 is therefore applied to the example fromFIG. 3. However, it is understood that the definition of a group amongthe of command receivers, explained with reference to FIG. 4, can beimplemented for purposes other than the pairing described with referenceto FIG. 3. In the case of home automation operators, the method of FIG.4 is implemented for the definition of a general command for centralisedprogramming of all the receivers or some of them. More generally, themethod of FIG. 4 is used for any sequence on the objects of a group—thegroup being defined by the initiator event.

Compared with the solution described at FIG. 3, the solution of FIG. 4ensures greater security, even if the distinct programming sequences areimplemented on the objects—which may in particular be the case if theoperators are programmed simultaneously in neighbouring apartments.

In the example of FIG. 4, the different objects send all the messages;this is relevant insofar as the different objects act as commandreceivers, and send their identifier to the command transmitter forpairing; to form a group, this solution is not mandated; it sufficesthat a single object provides to the others a time indication in orderthat the other objects can determine whether or not they belong to thesame group as that which has provided the indication. Thus the list ofobjects from a group could be generated by sending a command with a timeindication from an object; the other objects having the same timeindication could thus be declared. This solution limits the exchanges tothe extent that only the group members are declared.

The FIG. 4 solution is implemented simply by programming the commandreceivers to send a time reference in one or all messages.

FIG. 5 shows a flow chart of the method implemented in a bidirectionalobject used as a command receiver. An initiator event consisting of adouble power cut is assumed in the example of the figure, as describedin FIG. 3, without the time verification of FIG. 4. At the start (stage84), the command receiver is waiting for an initiator event. At stage86, the command receiver detects an initiator event; as explainedearlier, at stage 88 it sends its identifier and an indication that itis available for pairing; the possible repetition of this transmissionto manage collisions has not been shown at stage 88. The commandreceiver than waits for a temporary allocation command. At stage 90, itreceives a temporary allocation command and stores the identifier of thecommand transmitter to which it is allocated temporarily.

At stage 92, on receipt of a message, the command receiver checkswhether the message is from the command transmitter to which it has beenallocated. If this is not the case, it moves to stage 94, where themessage is ignored and reverts to waiting for a new message.

If the message received is from the command transmitter to which it isallocated, the command receiver executes the instructions contained inthe message. More precisely, it tests in 96 whether the instructions arepairing instructions. If this is the case, the receiver moves to 98,where it is paired and then operates in paired mode and responds only tothe transmitter to which it is paired. If the instructions are notpairing instructions, it tests in 100 whether these are releaseinstructions.

If this is the case, the command receiver is released without havingbeen paired; the program returns to stage 86, to wait for a newinitiator event; if not the receiver moves to stage 102, in which theinstructions are executed, and then returns to stage 92, to wait for anew message from the command transmitter to which it is paired. Theinstructions executed at stage 102 may be, for example, instructions toexecute a response command for visual identification of the commandreceiver via the product which it controls.

The flow chart of FIG. 5 does not show the case of a release after a setperiod, mentioned as an alternative solution in the description of FIG.3. The order of stages 96, 98, 100 and 102 could also be alternated, orsome of these stages could be eliminated, depending on the instructionssent during the temporary pairing.

FIG. 6 shows a flow chart of the method implemented in a bidirectionalobject used as a command transmitter; as in the example of FIG. 3, acommand transmitter using Stop and Prog buttons for the pairing processis assumed. The command transmitter is switched on at stage 110. Saidswitching on then makes the command transmitter sensitive totransmissions by command receivers of their identifier. This switchingon may consist of a particular action on the command transmitter; it maysimply be applying a voltage to the command transmitter, which isfollowed by automatic switching on.

At stage 112, the command transmitter receives transmissions from thecommand receivers and containing their identifiers; see stage 44 of FIG.3. The command transmitter can thus build up a list of command receiversavailable for a temporary allocation.

If the command receivers send a time reference, as explained at stage 74of FIG. 4, building up the list at stage 112 may involve comparing timereferences, as explained by reference to FIG. 4. From this point ofview, although the probability is low, it is possible in an installationsite covering, for example, several office floors or apartments thatthere is an overlap of two initiator events applying to a comparablenumber of objects. In this case, a consistency test of the timereferences sent by the command receivers cannot say which objects belongto the correct group. The consistency test is designed so as to rejectall identifiers if all are not in a consistent time slot, or even toreject all if the proportion of inconsistent identifiers exceeds a giventhreshold. In this case, all that has to be done is to trigger a newinitiator event to form the group.

It can also be envisaged that the various command receivers be declaredonly on receipt of a signal from the command transmitter, showing thatit is ready to receive their log in and their identifier. However, thisadds a stage and extends the internal clock counting time.

At stage 114, the command transmitter sends a temporary allocationcommand. This command is accompanied by a time reference if theprinciple proposed in FIG. 4 is used. This solution avoids temporaryallocation of command receivers which are not in the intended group. Atemporary allocation command can also be sent to command receivers onthe list; this is more certain, but prolongs the messages. In thebuttons example considered, the Prog button is used to trigger thisstage.

The user starts to scroll down the list at stage 116. The Stop buttoncan be used, for example. The Stop button can for example be used.Pressing on this button then causes the command transmitter to send aresponse command.

Following this response command, an new user command is waited for,stage 118. If the user presses the Stop button, he moves on to the nextcommand receiver—stage 120—and returns to stage 116. As explainedearlier, the order of scrolling through the list is immaterial.

If the user presses the Prog command at stage 118, he moves to stage122, which is the pairing stage. This stage consists of simply sending apairing command to the command receiver to which the response requesthas just been sent. Exchanges can also be simpler or more complex, asmentioned previously.

After this stage, a release command is sent, as shown at stage 124;either a second press on the Prog key is used, or a fresh press on theStop key, or any combination of keys. The program is then terminated andthe command transmitter is used in standard mode to control the pairedcommand receivers. As explained earlier, sending a release command isnot essential. Automatic release after a predetermined time is also anoption. Yet again, the list can be scrolled to pair another commandreceiver, as explained above; this avoids the need to build up a listagain for a new pairing.

The flow chart of FIG. 6 is schematic and, in particular, does not showsystematically the waiting stages before a user presses a button.

Of course, the invention is not limited to the embodiments given above.Thus, in the example of FIG. 3, the receiver in the list to be pairedcould also be chosen directly, without moving through stages 52, 54 and58. This could also be the case, for example, if a command transmitterhad to be paired to each receiver in any order. This could also be thecase if a programming console showing receiver identifiers is used as acommand transmitter allocated temporarily.

The radio transmission used between a transmitter and a receiver isgiven only by way of example and can be modified. The invention appliesin particular when the transmitters and receivers use a single frequencyor each transmit on a separate frequency, or by frequency hopping, orwith different modulations. In fact, the method applies immediatelycommand transmitters or command receivers are “bidirectional objects”capable of sending and receiving.

The terms “command receivers” and “operators” have been used, whichapply in particular to the example of rolling shutter operators. Thereceiver and the operator can be separate items, as in the examples, orform a single assembly—for example, by integrating the command receiverin the operator.

In the examples, transmitters send their address to the receiver whilesending a command; clearly, the relevant address can be coded orencrypted, by using techniques that are well known in the state of theart.

Specific embodiments of a method for pairing bidirectional objectsaccording to the present invention have been described for the purposeof illustrating the manner in which the invention may be made and used.It should be understood that implementation of other variations andmodifications of the invention and its various aspects will be apparentto those skilled in the art, and that the invention is not limited bythe specific embodiments described. It is therefore contemplated tocover by the present invention any and all modifications, variations, orequivalents that fall within the true spirit and scope of the basicunderlying principles disclosed and claimed herein.

1. A method for pairing a bidirectional object acting as a command receiver with a bidirectional object acting as a command transmitter, the command receiver having three distinct states: a first state in which the command receiver is not paired, a second state in which the command receiver is allocated temporarily to a command transmitter, and a third state in which the command receiver is paired to a command transmitter, the method comprising the following stages: (a) temporarily allocating a plurality of command receivers to a command transmitter, the temporary allocation moving the command receivers from the first state to the second state and rendering the command receiver responsive to only commands from the command transmitter to which it is allocated; then (b) selecting a command receiver from among the plurality of temporarily allocated objects by: (b1) the command transmitter sending a response request command to one of the temporarily allocated objects; (b2) the response request command recipient responding by sending a signal that allows a user to visually or audibly identify the response request command recipient; (b3) if the user determines that the response request command recipient is not a desired object for pairing, repeating the stage of sending a response request command, but to another of the temporarily allocated objects; and (b4) if the user determines that the response request command recipient is the desired object for pairing, proceeding to step (c); (c) sending a pairing command from the command transmitter to the command receiver, (c1) the command receiver moving from the second state to the third state upon receipt of the pairing command; and (c2) the command receiver being non-responsive to initiator events while in the third state, and then (d) releasing the temporarily allocated objects distinct from the paired object, the non-selected command receivers going from the second state to the first state.
 2. The method according to claim 1, further including an iteration of the selection (b) and pairing stages (c).
 3. The method according to claim 1, wherein the temporary allocation stage comprises: (a1) in response to an initiator event, sending by at least one bidirectional object acting as a command receiver of its identifier; (a2) sending by a bidirectional object acting as a command transmitter of its identifier; (a3) storage by a bidirectional object acting as a command receiver of the identifier of the bidirectional object acting as a command transmitter; and (a4) storage by the bidirectional object acting as the command transmitter of the identifier of each bidirectional object acting as a command receiver.
 4. The method according to claim 3, wherein the stage (a1) comprises sending with the identifier a time reference dependent at the instant of the initiator event.
 5. The method according to claim 4, wherein the stage (a4) comprises storage of the identifiers of the bidirectional objects acting as command receivers having identical or similar time references.
 6. The method according to claim 1, wherein the release stage (d) comprises releasing the temporarily allocated objects distinct from the paired object, in the absence of receiving a command during a set period.
 7. The method according to claim 1, wherein the release stage (d) comprises the release of a temporarily allocated object on receiving a pairing command addressed to another temporarily allocated object.
 8. The method according to claim 1, wherein the release stage(d) comprises the sending by the object acting as command transmitter of a release command.
 9. The method according to claim 1, wherein the pairing stage comprises the pairing to the selected object of the bidirectional object to which the selected object was allocated.
 10. The method according to claim 1, wherein the pairing stage comprises the pairing to the selected object of a different bidirectional object to the bidirectional object to which the selected object was allocated.
 11. A method of operating a bidirectional object acting as a command receiver having three distinct states: a first state in which the command receiver is not paired, a second state in which the command receiver is allocated temporarily to a bidirectional object acting as a command transmitter, and a third state in which the command receiver is paired to a command transmitter, the method comprising: (a) temporarily allocating the command receiver to the command transmitter, the temporary allocation causing the command receiver to move from the first state to the second state, the command receiver obeying any command received from the command transmitter to which it is allocated and only responding to the command transmitter to which it is allocated while it is in the second state; (b) transmitting a response request command from the command transmitter; (c) responding to the response request command sent by the command transmitter with a visual or audible signal that allows a user to identify the command receiver that received the response request command; and (d) receiving an instruction from the user after the sending of the visual or audible signal; (e) sending a pairing command from the command transmitter to be paired, to the command receiver that responded to the response request command; (f) changing the command receiver from the second state to the third state, the command receiver being non-responsive to an initiator event while it is in the third state.
 12. The method according to claim 11, wherein the temporary allocation stage comprises: (a1) in response to an initiator event, sending an identifier; (a2) receipt of an identifier; and (a3) storage of a received identifier.
 13. The method according to claim 12, wherein the sending stage comprises sending with the identifier a time reference dependent on the instant of the initiator event.
 14. The method according to claim 11, wherein the release stage comprises release on receipt of a pairing command addressed to another object.
 15. The method according to claim 11, wherein the release stage comprises release on receipt of a release command.
 16. The method according to claim 11, wherein the pairing stage comprises pairing to the said bidirectional object acting as the command transmitter.
 17. The method according to claim 11, wherein the pairing stage comprises pairing to a bidirectional object other than said object acting as the command transmitter.
 18. The method of claim 11, including a bidirectional object, the object having: a reception stage; a transmission stage; and a logic unit controlling the reception stage and the transmission stage.
 19. A method for operating a bidirectional object acting as a command transmitter comprises the following stages: (a) receipt and storage of the identifier of at least one bidirectional object acting as a command receiver having three distinct states, wherein in the first state the command receiver is not paired, in the second state the command receiver is allocated temporarily to the command transmitter and in the third state the command receiver is paired to a command transmitter; (b) sending a temporary allocation command to one of the objects whose identifier has been stored, said temporary allocation command prohibiting the command receiver from responding to other command transmitters and ensuring that the command receiver obeys any command received from the command transmitter to which it is allocated; (c) sending a response request command to one of the objects whose identifier has been stored, said object responding to the response request command with a visual or audible signal that allows the user to identify the command receiver; and (d) depending on an instruction from the user based on the visual or audible signal, sending a pairing command to said object by sending a pairing command using the command transmitter to be paired, said pairing command prohibiting said object from responding to an initiator event.
 20. The method according to claim 19, wherein stages (c) and (d) are repeated.
 21. The method according to claim 19, further including a sending stage (e) of a command releasing objects whose identifiers have been stored and separate from a paired object to which the pairing request command has been sent.
 22. The method according to claim 21, wherein the sending stage (e) comprises sending a release command.
 23. The method according to claim 19, wherein the reception stage comprises the comparison of received time references with said identifiers and storage of identifiers having the same or similar time references.
 24. The method according to claim 19, wherein the sending stage (c) comprises: (c1) sending a response request command to one of the objects whose identifier has been stored; (c2) sending a response request command to another of the objects whose identifier has been stored; and in that stage (d) comprises sending a pairing command to the object to which the previous response request command was addressed.
 25. The method according to claim 19, wherein in the stage (d), the pairing command includes the identifier of another object.
 26. The method of claim 19, including a bidirectional object, the object having: a reception stage; a transmission stage; and a logic unit controlling the reception stage and the transmission stage. 